Предметно-орієнтоване проєктування: Опанування обмежених контекстів для масштабованого програмного забезпечення

Предметно-орієнтоване проєктування (DDD) — це потужний підхід до вирішення складних програмних проєктів, що фокусується на основній предметній області. В основі DDD лежить концепція обмежених контекстів. Розуміння та ефективне застосування обмежених контекстів є вирішальним для створення масштабованих, підтримуваних і, зрештою, успішних програмних систем. Цей всеосяжний посібник заглибиться в тонкощі обмежених контекстів, досліджуючи як стратегічні, так і тактичні патерни, що використовуються.

Що таке обмежений контекст?

Обмежений контекст — це семантична межа в програмній системі, яка визначає застосовність конкретної моделі предметної області. Уявляйте його як чітко визначену область, де конкретні терміни та поняття мають послідовне й однозначне значення. Усередині обмеженого контексту єдина мова (Ubiquitous Language) — спільний словник, який використовують розробники та експерти предметної області, — є чітко визначеною та послідовною. Поза цією межею ті самі терміни можуть мати інші значення або взагалі бути нерелевантними.

По суті, обмежений контекст визнає, що єдина монолітна модель предметної області часто є непрактичною, якщо не неможливою, для створення у складних системах. Натомість DDD пропонує розбивати проблемну область на менші, більш керовані контексти, кожен зі своєю власною моделлю та єдиною мовою. Така декомпозиція допомагає керувати складністю, покращувати співпрацю та забезпечувати більш гнучку й незалежну розробку.

Навіщо використовувати обмежені контексти?

Використання обмежених контекстів надає численні переваги в розробці програмного забезпечення:

• Зменшення складності: Розділяючи велику предметну область на менші, більш керовані контексти, ви зменшуєте загальну складність системи. Кожен контекст легше зрозуміти та підтримувати.
• Покращення співпраці: Обмежені контексти сприяють кращій комунікації між розробниками та експертами предметної області. Єдина мова гарантує, що всі говорять однією мовою в межах конкретного контексту.
• Незалежна розробка: Команди можуть працювати незалежно над різними обмеженими контекстами, не заважаючи одна одній. Це дозволяє прискорити цикли розробки та підвищити гнучкість.
• Гнучкість і масштабованість: Обмежені контексти дозволяють розвивати різні частини системи незалежно. Ви можете масштабувати конкретні контексти відповідно до їхніх індивідуальних потреб.
• Покращення якості коду: Фокусування на конкретній предметній області в межах обмеженого контексту призводить до чистішого коду, який легше підтримувати.
• Відповідність бізнесу: Обмежені контексти часто відповідають конкретним бізнес-можливостям або відділам, що полегшує прив'язку програмного забезпечення до потреб бізнесу.

Стратегічне DDD: Визначення обмежених контекстів

Визначення обмежених контекстів є ключовою частиною фази стратегічного проєктування в DDD. Це включає розуміння предметної області, виявлення ключових бізнес-можливостей та визначення меж кожного контексту. Ось покроковий підхід:

1. Дослідження предметної області: Почніть із ретельного дослідження проблемної області. Спілкуйтеся з експертами, переглядайте наявну документацію та зрозумійте різні бізнес-процеси.
2. Визначення бізнес-можливостей: Визначте основні бізнес-можливості, які повинна підтримувати програмна система. Ці можливості представляють ключові функції, які виконує бізнес.
3. Пошук семантичних меж: Шукайте ділянки, де змінюється значення термінів або де застосовуються різні бізнес-правила. Ці межі часто вказують на потенційні обмежені контексти.
4. Врахування організаційної структури: Організаційна структура компанії часто може дати підказки щодо потенційних обмежених контекстів. Різні відділи або команди можуть відповідати за різні сфери предметної області. Тут дуже доречним є Закон Конвея, який стверджує, що "організації, які проєктують системи, змушені створювати проєкти, що є копіями комунікаційних структур цих організацій".
5. Накреслення карти контекстів: Створіть карту контекстів, щоб візуалізувати різні обмежені контексти та їхні взаємозв'язки. Ця карта допоможе вам зрозуміти, як різні контексти взаємодіють між собою.

Приклад: Система електронної комерції

Розглянемо велику систему електронної комерції. Вона може містити кілька обмежених контекстів, таких як:

• Каталог товарів: Відповідає за управління інформацією про товари, категорії та атрибути. Єдина мова включає такі терміни, як "товар", "категорія", "SKU" та "атрибут".
• Управління замовленнями: Відповідає за обробку замовлень, управління доставками та поверненнями. Єдина мова включає такі терміни, як "замовлення", "відправлення", "рахунок-фактура" та "оплата".
• Управління клієнтами: Відповідає за управління обліковими записами клієнтів, профілями та вподобаннями. Єдина мова включає такі терміни, як "клієнт", "адреса", "програма лояльності" та "контактна інформація".
• Управління запасами: Відповідає за відстеження рівня запасів та управління місцями зберігання. Єдина мова включає такі терміни, як "рівень запасу", "місцезнаходження", "точка перезамовлення" та "постачальник".
• Обробка платежів: Відповідає за безпечну обробку платежів та повернень коштів. Єдина мова включає такі терміни, як "транзакція", "авторизація", "розрахунок" та "дані картки".
• Система рекомендацій: Відповідає за надання рекомендацій товарів клієнтам на основі їхньої історії переглядів та поведінки покупок. Єдина мова включає такі терміни, як "рекомендація", "алгоритм", "профіль користувача" та "спорідненість товарів".

Кожен із цих обмежених контекстів має власну модель та єдину мову. Наприклад, термін "товар" може мати різні значення в контекстах каталогу товарів та управління замовленнями. У каталозі товарів він може стосуватися детальних специфікацій товару, тоді як в управлінні замовленнями — просто одиниці, що купується.

Карти контекстів: Візуалізація зв'язків між обмеженими контекстами

Карта контекстів — це діаграма, яка візуально представляє різні обмежені контексти в системі та їхні взаємозв'язки. Це найважливіший інструмент для розуміння того, як різні контексти взаємодіють, і для прийняття обґрунтованих рішень щодо стратегій інтеграції. Карта контекстів не заглиблюється у внутрішні деталі кожного контексту, а натомість зосереджується на взаємодіях між ними.

Карти контекстів зазвичай використовують різні позначення для представлення різних типів зв'язків між обмеженими контекстами. Ці зв'язки часто називають патернами інтеграції.

Тактичне DDD: Патерни інтеграції

Після того, як ви визначили свої обмежені контексти та створили карту контекстів, вам потрібно вирішити, як ці контексти будуть взаємодіяти один з одним. Саме тут починається фаза тактичного проєктування. Тактичне DDD зосереджується на конкретних патернах інтеграції, які ви будете використовувати для з'єднання ваших обмежених контекстів.

Ось деякі поширені патерни інтеграції:

• Спільне ядро (Shared Kernel): Два або більше обмежених контекстів використовують спільну модель або код. Це ризикований патерн, оскільки зміни у спільному ядрі можуть вплинути на всі контексти, що від нього залежать. Використовуйте цей патерн з обережністю і лише тоді, коли спільна модель є стабільною та чітко визначеною. Наприклад, кілька сервісів у фінансовій установі можуть спільно використовувати основну бібліотеку для розрахунків валют.
• Замовник-постачальник (Customer-Supplier): Один обмежений контекст (Замовник) залежить від іншого обмеженого контексту (Постачальник). Замовник активно впливає на модель Постачальника, щоб задовольнити свої потреби. Цей патерн корисний, коли один контекст має сильну потребу впливати на інший. Система управління маркетинговими кампаніями (Замовник) може суттєво впливати на розробку платформи клієнтських даних (Постачальник).
• Конформіст (Conformist): Один обмежений контекст (Конформіст) просто використовує модель іншого обмеженого контексту (Upstream). Конформіст не має впливу на модель Upstream і повинен адаптуватися до її змін. Цей патерн часто використовується при інтеграції з застарілими системами або сторонніми сервісами. Невеликий застосунок для продажів може просто відповідати моделі даних, наданій великою, усталеною CRM-системою.
• Антикорупційний шар (ACL): Шар абстракції, що знаходиться між двома обмеженими контекстами, перекладаючи їхні моделі. Цей патерн захищає downstream-контекст від змін в upstream-контексті. Це ключовий патерн при роботі з застарілими системами або сторонніми сервісами, які ви не можете контролювати. Наприклад, при інтеграції з застарілою системою нарахування заробітної плати, ACL може перетворити застарілий формат даних у формат, сумісний з HR-системою.
• Окремі шляхи (Separate Ways): Два обмежені контексти не мають жодного зв'язку один з одним. Вони повністю незалежні й можуть розвиватися окремо. Цей патерн корисний, коли два контексти є принципово різними і не потребують взаємодії. Внутрішня система відстеження витрат для співробітників може бути повністю відокремлена від публічної платформи електронної комерції.
• Відкритий сервіс-хост (OHS): Один обмежений контекст публікує чітко визначений API, який інші контексти можуть використовувати для доступу до його функціональності. Цей патерн сприяє слабкому зв'язку та дозволяє більш гнучку інтеграцію. API має бути розроблений з урахуванням потреб споживачів. Платіжний шлюз (OHS) надає стандартизований API, який різні платформи електронної комерції можуть використовувати для обробки платежів.
• Опублікована мова (Published Language): Відкритий сервіс-хост використовує чітко визначену та задокументовану мову (наприклад, XML, JSON) для комунікації з іншими контекстами. Це забезпечує сумісність та зменшує ризик неправильного тлумачення. Цей патерн часто використовується разом із патерном "Відкритий сервіс-хост". Система управління ланцюгами постачання надає дані через REST API, використовуючи JSON Schema для забезпечення чіткого та послідовного обміну даними.

Вибір правильного патерна інтеграції

Вибір патерна інтеграції залежить від кількох факторів, включаючи зв'язок між обмеженими контекстами, стабільність їхніх моделей та рівень контролю, який ви маєте над кожним контекстом. Важливо ретельно розглянути компроміси кожного патерна перед прийняттям рішення.

Поширені помилки та антипатерни

Хоча обмежені контексти можуть бути неймовірно корисними, існують також деякі поширені помилки, яких слід уникати:

• Великий клубок бруду (Big Ball of Mud): Нездатність правильно визначити обмежені контексти, що призводить до створення монолітної системи, яку важко зрозуміти та підтримувати. Це протилежність тому, чого прагне досягти DDD.
• Випадкова складність: Впровадження непотрібної складності шляхом створення занадто великої кількості обмежених контекстів або вибору невідповідних патернів інтеграції.
• Передчасна оптимізація: Спроба оптимізувати систему занадто рано, ще до повного розуміння предметної області та зв'язків між обмеженими контекстами.
• Ігнорування Закону Конвея: Нездатність узгодити обмежені контексти з організаційною структурою компанії, що призводить до проблем з комунікацією та координацією.
• Надмірна залежність від Спільного ядра: Занадто часте використання патерна "Спільне ядро", що призводить до сильного зв'язку та зменшення гнучкості.

Обмежені контексти та мікросервіси

Обмежені контексти часто використовуються як відправна точка для проєктування мікросервісів. Кожен обмежений контекст може бути реалізований як окремий мікросервіс, що дозволяє незалежну розробку, розгортання та масштабування. Однак важливо зазначити, що обмежений контекст не обов'язково має бути реалізований як мікросервіс. Він також може бути реалізований як модуль у більшому застосунку.

При використанні обмежених контекстів з мікросервісами важливо ретельно продумати комунікацію між сервісами. Поширені патерни комунікації включають REST API, черги повідомлень та подійно-орієнтовані архітектури.

Практичні приклади з усього світу

Застосування обмежених контекстів є універсальним, але специфіка буде відрізнятися залежно від галузі та контексту.

• Глобальна логістика: Міжнародна логістична компанія може мати окремі обмежені контексти для *Відстеження відправлень* (обробка оновлень місцезнаходження в реальному часі), *Митного оформлення* (робота з міжнародними правилами та документацією) та *Управління складом* (оптимізація зберігання та запасів). "Одиниця", що відстежується, має дуже різні представлення в кожному контексті.
• Міжнародний банкінг: Глобальний банк може використовувати обмежені контексти для *Роздрібного банкінгу* (управління індивідуальними рахунками клієнтів), *Комерційного банкінгу* (обробка бізнес-кредитів та транзакцій) та *Інвестиційного банкінгу* (робота з цінними паперами та торгівлею). Визначення "клієнта" та "рахунку" буде суттєво відрізнятися в цих сферах, відображаючи різноманітні регуляції та бізнес-потреби.
• Багатомовне управління контентом: Глобальна новинна організація може мати окремі обмежені контексти для *Створення контенту* (написання та редагування статей), *Управління перекладами* (обробка локалізації для різних мов) та *Публікації* (розповсюдження контенту різними каналами). Поняття "статті" має різні атрибути залежно від того, чи її пишуть, перекладають, чи публікують.

Висновок

Обмежені контексти — це фундаментальна концепція в предметно-орієнтованому проєктуванні. Розуміючи та ефективно застосовуючи обмежені контексти, ви можете створювати складні, масштабовані та підтримувані програмні системи, які відповідають потребам бізнесу. Не забувайте ретельно враховувати зв'язки між вашими обмеженими контекстами та обирати відповідні патерни інтеграції. Уникайте поширених помилок та антипатернів, і ви будете на правильному шляху до опанування предметно-орієнтованого проєктування.

Практичні поради

1. Починайте з малого: Не намагайтеся визначити всі обмежені контексти одразу. Почніть з найважливіших сфер предметної області та ітеруйте в міру отримання нових знань.
2. Співпрацюйте з експертами предметної області: Залучайте експертів протягом усього процесу, щоб переконатися, що ваші обмежені контексти точно відображають бізнес-домен.
3. Візуалізуйте вашу карту контекстів: Використовуйте карту контекстів для комунікації зв'язків між вашими обмеженими контекстами з командою розробки та зацікавленими сторонами.
4. Рефакторте постійно: Не бійтеся рефакторити ваші обмежені контексти в міру того, як ваше розуміння предметної області розвивається.
5. Приймайте зміни: Обмежені контексти не є викарбуваними в камені. Вони повинні адаптуватися до мінливих потреб бізнесу та технологічних досягнень.